Java Database Programming with JDBC Java Database Programming with JDBC
by Pratik Patel
Coriolis, The Coriolis Group
ISBN: 1576100561   Pub Date: 10/01/96
  

Previous Table of Contents Next


Chapter 11
Internet Database Issues: Middleware

The JDBC specification says that the JDBC API should serve as a platform for building so-called “three-tier” client/server systems, often called middleware. As you might imagine, these systems have three basic components: the client, the server, and the application server. Figure 11.1 shows the basic structure of a three-tier system.


Figure 11.1  Three-tier system structure.

In this chapter, I’ll provide you with the code necessary to implement a simple application server of your own. We’ll also take a look at building a client for our home-grown application server. But before we get to the coding, we first need to discuss why we would want to go to such lengths to build a three-tier system instead of allowing direct database access.

Several middleware solutions based on the JDBC are already available, and although you may ultimately decide to buy one from a vendor instead of coding one yourself, I feel that it’s important to learn the issues involved with middleware. Knowing the advantages and disadvantages that go along with inserting a middle tier to a system can help you decide if you need one.

Connectivity Issues Involved With Database Access

Let’s begin by examining some issues of database scalabilty that you are likely to encounter. The Internet and large intranet scenarios pose interesting dilemmas for databases that serve a large number of users:

  Concurrency—Suppose a user receives some data from the database server, and while the user is looking at it, the data on the database server is changed in some way. For the user to see the updated material, both the database server and the client need to be able to handle the change. While some database servers can handle the necessary coding (and the increased load on the server) for updating, some cannot.
  Legacy Databases—Some legacy database systems may not support simultaneous connections, or even direct connections using TCP/IP.
  Security—Most database servers do not support encrypted connections, which means that certain transactions, such as the login using a password, will not be secure. Over the Internet, such a lack of security is a major hole.
  Simultaneous Connections—Database servers have a limit on the number of active connections. Unfortunately, exceeding this predefined limit on the Internet is easy.

Advantages Of Middleware

Let’s now have a look at how a middle tier can address the issues presented in the previous section, while adding extra capability to a client/server system:

  Concurrency—You can program the application server to handle concurrency issues, off-loading the task from the database server. Of course, you would also need to program the clients to respond to update broadcasts. You can implement concurrency checking entirely on the application server, if necessary. This process involves checking to see if a specific data object requested by a client has changed since the current request, asking the client to update the previously retrieved data, and alerting the user.
  Legacy Databases—Databases that operate on older network protocols can be piped through an application server running on a machine that can communicate with the database server, as well as with remote Internet clients. A JDBC driver that can speak to a non-networked legacy database can be used to provide Internet access to its data, even using an ODBC driver, courtesy of the JDBC-ODBC Bridge. The application server can reside on the same machine as the non-networked database, and provide network access using a client that communicates to the application server.
  Security—You can program/obtain an application server that supports a secure connection to the remote clients. If you keep the local connection between the database server and the application server restricted to each other, you can create a fairly secure system. In this type of setup, your database server can only talk to the application server, so the threat of someone connecting directly to the database server and causing damage is greatly limited. However, you must be sure that there are no loopholes in your application server.
  Simultaneous Connections—The application server, in theory, can maintain only one active connection to the database server. On the other side, it can allow as many connections to itself from clients as it wants. In practice, however, significant speed problems will arise as more users attempt to use one connection. Managing a number of fixed connections to the database server is possible, though, so this speed degradation is not noticeable.

Disadvantages Of Middleware

Of course, middleware is not without its own pitfalls. Let’s take a brief look at some disadvantages you may encounter if you choose to implement an application server:

  Speed—As I’ve hinted, speed is the main drawback to running an application server, especially if the application server is running on a slow machine. If the application server does not run on the same machine as the database server, there may be additional speed loss as the two communicate with each other.
  Security—If your application server is not properly secured, additional security holes could easily crop up. For example, a rogue user could break into the application server, then break into the database server using the application server’s functions. Again, you must take great care to make sure that unauthorized access to the database server via the application server is not possible.
  Reliability—Adding an application server to the system introduces potential problems that may not be present in a two-tier system, where the clients are communicating directly with the database server.


Previous Table of Contents Next